Nowadays, there are scenarios where a user with a user's equipment (hereinafter UE) can negotiate with a telecommunication network, via a signalling layer, service requirements such as quality of service (hereinafter QoS) for a number of services, which are in fact carried through a separate bearer or connectivity layer provided by an access network. Amongst these scenarios, those providing an Internet Protocol (hereinafter IP) connectivity to users are particularly significant at present. In this context, the scenarios described throughout the present specification include a so-called IP Connectivity Access Network (hereinafter IP-CAN) where the users can exchange IP packets through. More specifically, a bearer or connectivity layer is a media transport, capable of carrying a plurality of IP flows, and takes place at the traffic plane. An IP flow is a unidirectional flow of IP packets with the same source IP address and port number, the same destination IP address and port number and, likely, the same transport protocol. An IP flow is thus used to transmit IP packets between an origin and a destination. Each IP flow may be associated with a service, and several IP flows may be associated with the same service.
For instance, a first scenario may be one where the user negotiates service requirements with an IP Multimedia Subsystem (hereinafter IMS), as specified in 3GPP TS 23.228 V7.5.0, whereas the services are actually carried through an IP-CAN such as a General Packet Radio Service (hereinafter GPRS) connectivity layer. In this first scenario, a Proxy Call Session Control Function (hereinafter P-CSCF) is an entry point to the IMS and is located in the signalling layer at the control plane thus aware of negotiated service requirements. On the other hand, the bearer layer in this first scenario is built up through a connection path established between the UE, a Serving GPRS Support Node (hereinafter SGSN), and a Gateway GPRS Support Node (hereinafter GGSN). A second scenario may be one where the user negotiates service requirements with an application server (hereinafter AS), such as a streaming server for video download services, whereas the services are actually carried through an IP-CAN such as a Wireless Local Area Network (hereinafter WLAN) connectivity layer. In this second scenario, the streaming server is the entity in charge of negotiating the service requirements with the UE, and is located in the signalling layer at the control plane; whereas the bearer layer is built up through a connection path between the UE, a WLAN Access Point (hereinafter WLAN AP), a WLAN Access Gateway (hereinafter WAG), and a Packet Data Gateway (hereinafter PDG). New scenarios might be apparent by having different combinations of signalling layer at the control plane with bearer layer at the traffic plane.
On the other hand, a common architecture called Policy and Charging Control (hereinafter PCC) is being currently developed under 3GPP TS 23.203 V2.0.0. This PCC is supposedly addressing all different types of access networks and is intended to control how media transported through the bearer layer is treated in view of corresponding service requirements negotiated through the signalling layer. In other words, the basic PCC architecture is suitable for being applied in scenarios where services are negotiated through the signalling layer, between user equipments and servers in the control plane; whereas said services are actually carried through the connectivity or bearer layer, possibly between originating and destination user equipments.
In accordance with 3GPP TS 23.203, the PCC architecture includes a so-called Policing and Charging Rules Function (hereinafter PCRF) in charge of defining network control for detection of particular IP flows associated with a given service, making decisions based on information received from the signalling layer by creating control rules to enforce the negotiated service requirements into the bearer layer, as well as notifying the service layer about significant events occurred in the bearer layer for the given service. This PCRF is preferably located in an intermediate entity enabled to communicate with a first entity in the control plane and with a second entity in the traffic plane. The PCC architecture also includes a so-called Policing and Charging Enforcement Function (hereinafter PCEF) in charge of detecting those particular IP flows associated with a given service, and enforcement at the bearer layer of those service requirements negotiated through the signalling layer by installing the above control rules received from the PCRF. The PCEF may be included in the traffic plane and supports the connectivity or bearer layer between originating and destination user equipments. Apart from the PCEF and PCRF, the PCC architecture also includes an application function (hereinafter AF) for offering applications that require control of the IP bearer resources. In particular, the AF may reside in, or be an integral part of, a server in the control plane aware of negotiated service requirements. The AF communicates with the PCRF to transfer dynamic session information, namely service information including the negotiated service requirements, required for PCRF decisions and for creation of the control rules.
Regarding the above exemplary scenarios, and prior to registering a user in an application at the control plane such as the IMS or an appropriate application server, namely at the signalling layer, the user has to establish a bearer through the IP-CAN, that is, at the bearer layer. In particular, where the IP-CAN is a GPRS access network and the user intends to register into an IMS network, the user has to firstly activate a primary Packet Data Protocol (hereinafter PDP) Context through the GPRS access network for bearing the IMS signalling. An IMS network generally makes use of a Session Initiation Protocol (hereinafter SIP) so that, for the purpose of the present discussion, IMS signalling is conventionally understood as SIP signalling. Likewise, the establishment of a bearer through the IP-CAN is understood as the activation of a primary PDP Context in scenarios having a GPRS access network as IP-CAN. Then, once the user has established a bearer through the IP-CAN, the user can register in the application at the control plane and can negotiate with the exemplary IMS, or with the exemplary AS, or with a destination user the service requirements to be applied to the transmission of media through the bearer layer.
For instance, in the above first scenario where the user intends to access the IMS through a GPRS IP-CAN as illustrated in FIGS. 1a and 1b, the user requests the activation of a primary PDP Context, which is received at a GGSN via a SGSN. The GGSN submits a so-called CCR message towards the PCRF in order to request preconfigured rules to apply for the primary PDP Context for a given user. The PCRF obtains in co-operation with a subscription profile repository (hereinafter SPR) those applicable preconfigured rules indicating the services supported for the given user, and sends them back with a CCA message. Then, the GGSN confirms back to the user the activation of the primary PDP Context.
Once a bearer has been established for bearing the IMS signalling, the user can register into the IMS. To this end, the user submits a SIP Register message towards the P-CSCF, which is the entry point to the IMS and, once the user's registration has been accepted by the IMS and a Serving Call Session Control Function (hereinafter S-CSCF) has been assigned for servicing the user, the user is acknowledged with a SIP OK message indicating a successful registration. The user might want to establish a communication session with a destination user and submits a SIP Invite message to this end. At this stage, a number of service parameters, namely service requirements, are negotiated between the user equipments involved in the communication and likely the network. These service requirements are negotiated through the P-CSCF with a so-called Service Data Protocol (hereinafter SDP), and the P-CSCF eventually submits the negotiated service requirements back to the PCRF with a so-called AAR message including, amongst others, information of the media components for the negotiated communication session, the type of media (e.g. audio or video, etc), and the negotiated QoS parameters.
In a more generic scenario and in accordance with the PCC architecture basically described above, the service requirements are negotiated through the so-called AF, which sends them to the PCRF and which role is, in this first scenario, carried out by the P-CSCF. Upon receipt of these service requirements, the PCRF can determine the control rules to apply and can install them in the PCEF.
At this stage, the PCRF has to decide whether installing the control rules for the bearer presently established through the IP-CAN, which in this first scenario is the primary PDP Context where the user has registered into the IMS through the GPRS network, or waiting for the establishment of a further dedicated bearer for the negotiated service as the current trends suggest for the coming generation of user equipments.
If the PCRF decides to wait for a further dedicated bearer to be established for the negotiated service, and the UE currently used by the user in the above first exemplary scenario is capable of establishing further bearers, the GGSN may receive a request for activation of a secondary PDP Context via the SGSN. This request for activation of the secondary PDP Context activation is expected to include information that further allows the PCRF to identify the communication session and service requirements previously received from a P-CSCF or, more generally, from an AF where the service had been negotiated through. The GGSN submits towards the PCRF in the so-called CCR this information relevant for identifying the control rules to apply, and the PCRF returns back with the so-called CCA to the GGSN the control rules to be installed therein. Generally speaking, the PCRF returns to the PCEF the control rules to be installed and applied and, in this first scenario, the GGSN behaves as, or includes, the functionality of the PCEF as described in the PCC architecture. Then, once the control rules are installed at the GGSN, or more precisely at the PCEF included in the GGSN, the activation of the secondary PDP Context is confirmed back to the user, and the communication session is eventually confirmed from the PCRF towards the AF or, in this first scenario, towards the P-CSCF that includes the AF functionality.
However, if the PCRF has decided to wait for establishment of a subsequent bearer and the UE is not capable of supporting the establishment of subsequent bearers, the awaiting control rules will not be installed and the service cannot be carried out.
On the other hand, if the PCRF has decided to install the created control rules immediately for the already established bearer, and the user further requests the establishment of a subsequent bearer, the process of negotiating service requirements might be repeated though the other end, either the exemplary IMS, the exemplary AS, or a destination user, might understand the establishment of a new communication session with the same user.